Results for oCISSharingInternal3 https://drone.owncloud.com/owncloud/web/22425/61/1
The following scenarios passed on retry:

• webUISharingInternalUsersSharingIndicator/shareWithUsers.feature:17

Results for oC10iPhone1 https://drone.owncloud.com/owncloud/web/22431/48/1
💥 The acceptance tests pipeline failed. The build has been cancelled.

Results for oCISFiles3 https://drone.owncloud.com/owncloud/web/22431/57/1
💥 The acceptance tests pipeline failed. The build has been cancelled.

Results for oCISSharingInternal1 https://drone.owncloud.com/owncloud/web/22431/59/1
💥 The acceptance tests pipeline failed. The build has been cancelled.

Results for oCISSharingBasic https://drone.owncloud.com/owncloud/web/22431/53/1
💥 The acceptance tests pipeline failed. The build has been cancelled.

Results for oCISSharingAutocompletion https://drone.owncloud.com/owncloud/web/22431/62/1
💥 The acceptance tests pipeline failed. The build has been cancelled.

Results for e2e-tests oC10 https://drone.owncloud.com/owncloud/web/22813/10/1

Results for e2e-tests oC10 https://drone.owncloud.com/owncloud/web/22833/10/1

Results for oC10iPhoneNotifications https://drone.owncloud.com/owncloud/web/22861/47/1
💥 The acceptance tests pipeline failed. The build has been cancelled.

Results for oC10XGAPortraitNotifications https://drone.owncloud.com/owncloud/web/22861/43/1
💥 The acceptance tests pipeline failed. The build has been cancelled.

In general this PR is good to go. But there is an issue in playwright vs. nightwatch tests: I don't know the reason, but with this PR the playwright (e2e) tests for ownCloud 10 stop with a timeout on the Authorize oauth2 page. That's why I created 5a43820 to set web as trusted client. For the playwright tests this works. But the nightwatch based test suite has some tests that wait for the authorization page of the oauth2 app.

@phil-davis @individual-it do you have an opinion on this? I didn't find out why the playwright tests now timeout on the authorize page. PR diff doesn't give a hint for me. Could you invest time with high prio to unblock this PR? I'm fine with setting web as trusted client and removing the respective tests for the authorize page in the acceptance test suite. That somehow feels like testing vendor code anyway (checking the fact that the oauth2 page redirects to web after clicking authorize is indirectly testing the oauth2 app instead of web).

@saw-jan will be investigating the above-mentioned case.

Results for oC10Notification https://drone.owncloud.com/owncloud/web/22879/40/1

Do you think it makes sense to make both test suites able to deal with an existing or absent oauth2 authorize page? Meaning: Shortly waiting if it's there, if yes, click authorize, if not, already done with the step? This would still mean that we need to get rid of scenarios or steps in scenarios where we actively wait for the authorize page to appear. How much effort would that be?

Results for oCISBasic https://drone.owncloud.com/owncloud/web/22881/51/1
💥 The acceptance tests pipeline failed. The build has been cancelled.

Do you think it makes sense to make both test suites able to deal with an existing or absent oauth2 authorize page? Meaning: Shortly waiting if it's there, if yes, click authorize, if not, already done with the step? This would still mean that we need to get rid of scenarios or steps in scenarios where we actively wait for the authorize page to appear. How much effort would that be?

That approach can be implemented but the problem would the wait time.
Since we need to login on every tests, wait time might affect the test run time cumulatively (by how much extent is unknown)

Results for oC10Notification https://drone.owncloud.com/owncloud/web/22882/40/1

Results for oC10XGAPortrait2 https://drone.owncloud.com/owncloud/web/22882/45/1
💥 The acceptance tests pipeline failed. The build has been cancelled.

@kulmann , After logging in if we do not wait for some seconds then the login page reappears instead of files page.
And waiting for some seconds after submitting a login form works.
This happens in the tests but cannot reproduce manually. Do you have any idea why that happens?

Results for oCISTrashbinUploadMoveJourney https://drone.owncloud.com/owncloud/web/22948/69/1
The following scenarios passed on retry:

• webUIUserJourney/journey1.feature:11

Results for oCISSharingInternal2 https://drone.owncloud.com/owncloud/web/22948/60/1

Results for oCISFiles1 https://drone.owncloud.com/owncloud/web/22948/55/1
The following scenarios passed on retry:

• webUIDeleteFilesFolders/deleteFilesFolders.feature:12

Results for oC10Files1 https://drone.owncloud.com/owncloud/web/22948/16/1

Results for oCISFiles2 https://drone.owncloud.com/owncloud/web/22948/56/1

Results for oC10IntegrationApp1 https://drone.owncloud.com/owncloud/web/22948/71/1

Results for oC10Files2 https://drone.owncloud.com/owncloud/web/22948/17/1

Results for oC10Notification https://drone.owncloud.com/owncloud/web/22951/40/1

@fschade @kulmann The real issue was that after the login, the page gets refreshed too early in the tests (which might have prevented some storage or cookies to be set thus causing redirect to login page).
I will be pushing a possible fix.

But it is still a mystery why that happens only in that docker setup (web served via apache and service name used as URL e.g. http://web)

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

82.5% Coverage
0.0% Duplication

Results for oCISSharingPublic1 https://drone.owncloud.com/owncloud/web/22955/67/1
The following scenarios passed on retry:

• webUISharingPublicBasic/publicLinkCreate.feature:190

@saw-jan many thanks 😗

@fschade did you see my comments above?

@diocas

Instead of , you want or am I missing something?;

there's no need to close the base tag https://www.w3schools.com/tags/tag_base.asp#:~:text=The%20tag%20specifies%20the,inside%20the%20element.

I had previously written in here that js and css had relative paths, but it looks like it's just css. If I do not start in / (i.e go to cbox.cern.ch/some/page), the css never gets loaded)

thanks, i create a separate PR for this, the problem we have right now is that we first have to add the base tag to oc10 because it's located in /index.php/apps/web/index.html and having /css/app.css without the base tag could break it.

If I land in a route that doesn't exist, I only see a white page (with the branding header, if the css loads) and maybe it should be a 404;

Yes 404 must be handled inside web (vue) when using the history mode, this is because of the try_file pattern. We need to add those pages in a separate PR

The login page is appearing with the header instead of just being a simple page.. But this might've been some issue when I rebased our changes;

please keep my in the loop if theres something we can do.

the problem was not closing the tag, it's that in ocis (and I think your code) it uses href but you document src (including the changelog), which when I tried was breaking all the redirections. (edit: I've just read the page you sent, and it needs to be href)
For the others, yes, I'll be waiting for the PRs (including the 404 page, which was exactly what I wanted :) ).
Do you have an estimate btw? To know if I need to remove the functionality for now or if the fixes will come soon enough.

@diocas not now, in my opinion we should tackle those fast (i can't decide exactly by when). Now i first need to work on #6327 and #5863

ok, thanks. In the meantime I did a quick fix for the most visible issue (the css not loading), so I think we're good. I'll check the login page with the header issue.